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Review of Roaming Implementations 
Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document reviews the design and functionality of existing 
roaming implementations. "Roaming capability" may be loosely defined 
as the ability to use any one of multiple Internet service providers 
(ISPs), while maintaining a formal, customer-vendor relationship with 
only one. Examples of cases where roaming capability might be 
required include ISP "confederations" and ISP-provided corporate 
network access support. 


Introduction 


Considerable interest has arisen recently in a set of features that 
fit within the general category of "roaming capability" for Internet 
users. Interested parties have included: 


Regional Internet Service Providers (ISPs) operating within a 
particular state or province, looking to combine their efforts 
with those of other regional providers to offer service over a 
wider area. 


National ISPs wishing to combine their operations with those of 
one or more ISPs in another nation to offer more comprehensive 
service in a group of countries or on a continent. 


Businesses desiring to offer their employees a comprehensive 
package of access services on a global basis. Those services may 
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include Internet access as well as secure access to corporate 
intranets via a Virtual Private Network (VPN), enabled by 
tunneling protocols such as PPTP, L2F, or L2TP. 


What is required to provide roaming capability? The following list 
is a first cut at defining the requirements for successful roaming 
among an arbitrary set of ISPs: 


Phone number presentation 

Phone number exchange 

Phone book compilation 

Phone book update 

Connection management 
Authentication 

NAS Configuration/Authorization 
Address assignment and routing 
Security 

Accounting 


In this document we review existing roaming implementations, 
describing their functionality within this framework. In addition to 
full fledged roaming implementations, we will also review 
implementations that, while not meeting the strict definition of 
roaming, address several of these problem elements. These 
implementations typically fall into the category of shared use 
networks or non-IP dialup networks. 


3.1. Terminology 


This document frequently uses the following terms: 


home ISP This is the Internet service provider with whom the user 
maintains an account relationship. 


local ISP This is the Internet service provider whom the user calls 
in order to get access. Where roaming is implemented the local 
ISP may be different from the home ISP. 


phone book 
This is a database or document containing data pertaining to 
dialup access, including phone numbers and any associated 
attributes. 
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shared use network 
This is an IP dialup network whose use is shared by two or 
more organizations. Shared use networks typically implement 
distributed authentication and accounting in order to 
facilitate the relationship among the sharing parties. Since 
these facilities are also required for implementation of 
roaming, implementation of shared use is frequently a first 
step toward development of roaming capabilities. In fact, one 
of the ways by which a provider may offer roaming service is 
to conclude shared use agreements with multiple networks. 
However, to date the ability to accomplish this has been 
hampered by lack of interoperability among shared use 
implementations. 


non-IP dialup network 
This is a dialup network providing user access to the member 
systems via protocols other than IP. These networks may 
implement phone book synchronization facilities, in order to 
provide systems, administrators and users with a current list 


of participating systems. Examples of non-IP dialup networks 
supporting phone book synchronization include FidoNet and 
WWIVnet. 


4. Global Reach Internet Consortium (GRIC) 


Led by a US-based Internet technology developer, AimQuest 
Corporation, ten Internet Service Providers (ISPs) from the USA, 
Australia, China, Japan, Hong Kong, Malaysia, Singapore, Taiwan, and 
Thailand formed the Global Reach Internet Connection (GRIC) in May, 
1996. The goals of GRIC were to facilitate the implementation of a 
global roaming service and to coordinate billing and settlement among 
the membership. Commercial operation began in December of 1996, and 
GRIC has grown to over 100 major ISPs and Telcos from all over the 
world, including NETCOM, USA; KDD and Mitsubishi, Japan; iStar, 
Canada; Easynet, UK; Connect.com, Australia; Iprolink, Switzerland; 
Singapore Telecom; Chunghwa Telecom, Taiwan; and Telekom Malaysia. 
Information on GRIC is available from http://www.gric.net/. 


In implementing their roaming service, GRIC members have chosen 
software developed by AimQuest. AimQuest Corporation’s roaming 
implementation comprises the following major components: the 
AimTraveler Authentication Server (AAS), the AimTraveler Routing 
Server (ARS), and the AimQuest Internet Management System (AIMS), 
software designed to facilitate the billing process. Information on 
the AimQuest roaming implementation is available from 
http://www.aimquest.com/. 
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The AimTraveler Authentication Server (AAS) runs at each member ISP 
location, and handles incoming authentication requests from NAS 
devices and other AASes. The AimTraveler Routing Server (ARS) can run 
anywhere. A single routing server can be used where centralized 
routing is desired, or multiple routing servers can be run in order 
to increase speed and reliability or to gateway to networks of 
particularly large partners. 


The first version of the AimTraveler software, deployed by AimQuest 
in May, 1996, supported direct authentication between members of the 
roaming consortium, but as GRIC grew, management of the relationships 
between the authentication servers became a problem. In August. 1996, 
AimQuest began development of the AimTraveler Routing Server (ARS) in 
order to improve scalability. 


The routing server is comprised of two elements: The Central 
Accounting Server and the Central Routing Server. The Central 
Accounting Server collects all the roaming accounting data for 
settlement. The Central Routing Server manages and maintains 
information on the authentication servers in the roaming consortium. 
Adding, deleting, or updating ISP authentication server information 
(e.g. adding a new member ISP) may be accomplished by editing of a 
configuration file on the Central Routing Server. The configuration 
files of the AimTraveler Authentication Servers do not need to be 
modified. 


The AimTraveler Authentication and Routing Servers are available for 
various UNIX platforms. Versions for Windows NT are under 
development. The AimTraveler Authentication Server supports both the 
UNIX password file and Kerberos. 


The AimQuest Internet Management System (AIMS) is designed for large 
ISPs who need a centralized management system for all ISP operations, 
including sales, trouble-ticketing, service, and billing. AIMS 
produces usage and transaction statement reports, and includes a 
settlement module to produce settlement/billing reports for the 
roaming consortium members. Based on these reports, the providers 
charge their ISP/roaming customers, and pay/settle the roaming 
balance among the providers. AIMS currently runs on 
Sun/Solaris/Oracle. A version for Windows NT and SQL Server is 
expected to become available in Q4 1996. 


4.1. Phone number presentation 
Currently there are two principal methods by which GRIC users can 
discover available phone numbers: a Web-based directory provided by 


the GRIC secretariat, and a GRIC phone book client on the user PC 
with dialing capability. 
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4.1.1. Web based directory 


A directory of GRIC phone numbers is available on the GRIC home page, 
http://www.gric.com/. The list of numbers is arranged by country and 
provider. For each provider within a country, this directory, 
provided in the form of a table, offers the following information: 


Provider address, voice phone and fax 
Customer support phone number 
Provider domain name 

Primary Domain Name Server 

Secondary Domain Name Server 

Dial-up IP Address 

News server 

Web page 

POP phone numbers (i.e. 1-408-366-9000) 
POP locations (i.e. Berkeley) 

Proxy addresses 

Dialer configuration 


In order to discover phone numbers using the Web-based directory, it 
is expected that users will be online, and will navigate to the 
appropriate country and provider. They then look up the number and 
insert it into the AimQuest Ranger dialer. 


4.1.2. GRIC phone book client 


The GRIC phone book client software provides for phone book 
presentation as well as automated updating of phone numbers. The 
GRIC phone book includes a list of countries, states, cities and 
area/city codes, as well as detailed provider information, including 
the cutomer support phone number, and Internet server configuration 
info. The Phone book, developed with Java, is available for download 
from the AimQuest Web site: 


http://www.aimquest.com/dialer.html 
4.2. Phone number exchange 
GRIC members submit information both about themselves and their POPs 
to the GRIC secretariat, which is run by AimQuest. The GRIC 
secretariat then compiles a new phone book and provides updates on 


the GRIC FTP and Web servers. 


GRIC users then download the phone numbers either in Windows .ini 
file format or in HTML. 


Aboba, et. al. Informational [Page 5] 


RFC 2194 Review of Roaming Implementations September 1997 


4.3. Phone book compilation 


GRIC phone books are compiled manually, and represent a concatenation 
of available numbers from all the members of the roaming consortium, 
with no policy application. As new POPs come online, the numbers are 
forwarded to GRIC, which adds them to the phone book servers. 


4.4. Phone book update 


Phone numbers in the GRIC phone book client are updated automatically 
upon connection. The AimTraveler server includes an address book 
which contains the phone numbers of all the roaming consortium 
members. 


4.5. Connection management 


The AimTraveler software supports SLIP and PPP, as well as PAP and 
CHAP authentication. 


4.6. Authentication 


GRIC implements distributed authentication, utilizing the user’s e- 
mail address as the userID (i.e. "liu@Aimnet.com") presented to the 
remote NAS device. 


After the initial PPP authentication exchange, the userID, domain, 
and pasword information (or in the case of CHAP, the challenge and 
the response) are then passed by the NAS to the AimTraveler 
Authentication Server which supports both TACACS+ and RADIUS. 


If the authentication request comes from a regular customer login, 
normal user id and password authentication is performed. If the user 
requesting authentication is a "roamer," (has a userID with an @ and 
domain name), the authentication server sends an query to the closest 
routing server. When AimTraveler Routing Server receives the 
authentication request, it first authenticates the AAS sending the 
request, and if this is successful, it checks its authentication 
server table. If it is able to match the domain of the user to that 
of a "Home ISP", then the Home ISP authentication server’s routing 
information are sent back to the local ISP’s authentication server. 
Based on the information received from the routing server, the AAS 
makes an authentication request to the user’s Home ISP AAS for user 
id and password verification. 


If the user is a valid user, the Home ISP authentication server sends 
a "permission granted" message back to the Local ISP authentication 
server. The Local ISP authentication server then requests the NAS to 
grant the user a dynamic IP address from its address pool. If the 


Aboba, et. al. Informational [Page 6] 


RFC 2194 Review of Roaming Implementations September 1997 


username or password is incorrect, the Home ISP AAS will send a 
rejection message to the Local ISP AAS, and the user will be dropped 
by the NAS. 


If multiple routing servers are installed, and the query to the first 
routing server does not result in a match, the query is forwarded to 
the next routing server. The server queries are cached on the routing 
servers, improving speed for repeated queries. The cache is sustained 
until a routing server table entry is updated or deleted. Updating 
or deleting results in a message to all neighbor routing servers to 
delete their caches. 


The local authentication server also receives the accounting data 
from the NAS. If the data is for a regular customer login, the data 
is written to the Local ISP AAS log file. If the data is fora 
"roamer," the data is written to three places: the Local ISP AAS log 
file, the Home ISP AAS log file, and the ARS log file. 


If the local ISP authentication server has caching turned on, then it 
will cache information on Home ISP authentication server 
configurations sent by the routing server. This means that if the 
same domain is queried again, the local authentication server does 
not need to query the routing server again. The local cache is 
cleared when the local authentication server receives an update 
message from the routing server or system manager. 


4.7. NAS Configuration/Authorization 


AimTraveler is comprised of two components, a Client (AAS) anda 
Server (ARS). 


The AimTraveler Client acts as the PPP dial-up authentication server. 
When it detects an ’@’ sign in the userID field, it queries the 
AimTraverler Server for routing information, then forwards the 
authentication request to user’s home authentication server. The 
AimTraveler Server, a centralized routing server, contains the 
authorized ISP’s domain name, authentication servers and other 
information. 


The AimTraveler currently supports RADIUS and TACACS+, and could be 
extended to support other authentication protocols. It also receives 
all the accounting records, which are subsequently used as input data 
for billing. 


Since ISPs’ NAS devices may be configured differently, the attributes 
returned by the home ISP AAS are discarded. 
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4.8. Address assignment and routing 


All addresses in GRIC are assigned dynamically from within the 
address pool of the local ISP. Static addresses and routed LAN 
connections will be considered in the future, when GRIC offers 
corporate roaming service, with the implementation of tunneling 
protocols 


4.9. Security 


The user’s password is hashed with MD5 before being sent from the 
Local ISP AAS to the Home ISP AAS. An encryption key is shared 
between the AAS and ARS. The current version of AimTraveler AAS does 
not support token cards or tunneling protocols. 


4.10. Accounting 


The AimTraveler Authentication Server (AAS) software can act as 
either a RADIUS or TACACS+ accounting server. When accounting 
information is received from the NAS, the local AimTraveler 
Authentication Server (AAS) sends accounting data (user name, domain 
name, login time) to both the Central Accounting Server (part of the 
ARS) and the user’s Home ISP AimTraveler authentication server. In 
the case of GRIC, the Central Accounting Server is run by AimQuest. 


The data sent to the central accounting server and home ISP are 
identical except for the form of user id and time stamp. For a 
traveler whose home ISP is in the US, but who is traveling in Japan, 
the Local (Japanese) ISP AimTraveler authentication server will 
receive an accounting record timestamped with Japan time while the 
Home (US) ISP AimTraveler authentication server will receive an 
accounting record timestamped with the appropriate US timezone. 


The accounting data includes 2 new attributes for settlement 


reporting: 
Attribute Number Type 
Roaming-Server-ID 101 string 
Isp-ID 102 string 


The Roaming-Server-ID attribute identifies the AAS sending the 
authentication request. The Isp-ID attribute identifies the local 
ISP. Using this information the home ISP can track the roaming 
activities of its users (where their users are logging in). 
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5. 


5. 


5 


The AimTraveler Server running at AimQuest keeps a record of all 
roaming transactions, which are used as input to the settlement and 
billing process. At the end of each month, AimQuest provides a 
roaming transaction summary to GRIC members using AIMS. The AIMS 
software is configurable so that it takes into account the settlement 
rules agreed to by GRIC members. 


i-Pass implementation 
1. Overview 


i-Pass Alliance Inc., based in Mountain View, California, has 
developed and operates a commercial authentication and settlement 
clearinghouse service which provides global roaming between Internet 
service providers. The service is fully operational. 


i-Pass Alliance Inc. has additional offices in Toronto, Singapore, 
and London. More information on i-Pass can be obtained from 
http://www.ipass.com. 


The i-Pass network consists of a number of servers that provide 
real-time authentication services to partner ISPs. Authentication 
requests and accounting records for roaming users are encrypted and 
sent to an i-Pass serverwhere they are logged, and then forwarded to 
a home ISP for authentication and/or logging. 


Periodically, i-Pass reconciles all accounting records, generates 
billing statements, and acts as a single point for collecting and 
remitting payments. 


i-Pass provides its service only to ISPs and channel partners. It 
does not attempt to establish a business relationship with 
individual-user customers of an ISP. 


-2. Access Point Database (APD) 


i-Pass maintains a list of roaming access points in an Oracle 
database. This list is searchable by geographical region using a Web 
browser, and may be downloaded in its entirety using FTP. The 
information stored for each access point includes: 


Name of service provider 
Country 

State or Province 

City or Region 

Telephone number 

Technical support phone number 
Service types available 


Aboba, et. al. Informational [Page 9] 


RFC 2194 Review of Roaming Implementations September 1997 
Technical information (help file) 
Service pricing information 


The Access Point Database is maintained by i-Pass staff, based on 
input from i-Pass partners. 


5.3. Phone number presentation 
ni-Pass has developed a Windows application wth a simple point and 


click interface called the "i-Pass Dial Wizard", which assists end- 
users in selecting and connecting to a local Internet access point. 


The Dial Wizard allows users to first select the country in which 
they are roaming. A list of states, provinces, or other regions in 
the selected country is then presented. Finally a list of access 
points within the state or province is presented. The Dial Wizard 
displays the city name, modem phone number, and price information for 
each access point within the state or region. 


When the user selects the desired access point, a Windows 95 "DialUp 
Networking" icon is created for that access point. If there is a 
login script associated with the access point, the DialUp Scripting 
tool is automatically configured. This means that end-users never 
have to configure any login scripting requirements. 


The Dial Wizard has a built-in phonebook containing all the i-Pass 
access points. The phonebook may be automatically refreshed from a 
master copy located onISPs web site. 


The Dial Wizard is provided free of charge to i-Pass partners. i- 
Pass also provides the i-Pass Dial Wizard Customization Kit which 
allows ISP partners to generate customized versions of the Dial 
Wizard with their own logo, etc. 


5.4. Authentication 


There are three entities involved in servicing an authentication 
request: 


Local ISP At the local ISP, the authentication server is modified to 
recognize user IDs of the form username@auth_domain as being 
remote authentication requests. These requests are forwarded 
to an i-Pass server. 
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i-Pass Server 
The i-Pass server receives the authentication request, logs 
it, and forwards it to the home ISP identified by the 
auth_domain portion of the user ID. 


Home ISP The home ISP receives the authentication request, performs 
authentication using its normal authentication method, and 
returns a YES/NO response to the i-Pass server, which in turn 
forwards the reply to the originating ISP. 


i-Pass provides software components which run on the authentication 
servers of the local and home ISPs. Each member ISP must integrate 
these components with the native authentication method being used by 
the ISP. To simplify this task, i-Pass has developed "drop-in" 
interfaces for the most commonly used authentication methods. At the 
date of writing, the following interfaces are supported: 


Livingston RADIUS 

Ascend RADIUS 

Merit RADIUS 

TACACS+ 

Xylogics erpcd (Versions 10 and 11) 


A generic interface is also provided which authenticates based on the 
standard UNIX password file. This is intended as a starting point 
for ISPs using authentication methods other than those listed above. 


The software integration effort for a typical ISP is on the order of 
2-5 man-days including testing. Platforms currently supported 
include: 


Solaris 
Solaris 
BSDI 
Digital Unix 
Linux 
FreeBSD 

HP /UX 


(Sparc) .LI 


ISPs may chooe to provide authentication for their end-users roaming 
elsewhere, but not to provide access points to the i-Pass network. 
In this case the software integration effort is greatly reduced and 
can be as little as 1/2 a man-day. 


5.5. Accounting 


Accounting transactions are handled in the same way as authentication 
requests. In addition to being logged at the i-Pass servers, 
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accounting transactions are sent in real-time to the home ISP. This 
is intended to allow ISPs to update users’ credit limit information 
on a real-time basis (to the extent that this capability is supported 
by their billing and accounting systems). 


Settlement is performed monthly. The settlement process involves 
calculating the costs associated with each individual session, and 
aggregating them for each ISP. A net amount is then calculated which 
is either due from i-Pass to the ISP, or from the ISP to i-Pass, 
depending on the actual usage pattern. 


The following reports are supplied to member ISPs: 


A Monthly Statement showing summaries of usage, service provided, 
and any adjustments along with the net amount owing. 


A Call Detail Report showing roaming usage by the ISP’s customers. 


A Service Provided report showing detailed usage of the ISP’s 
facilities by remote users. 


The above reports are generated as ASCII documents and are 
distributed to i-Pass partners electronically, either by e-mail or 
from a secure area on the i-Pass web site. Hard-copy output is 
available on request. 


The Call Detail Report is also generated as a comma-delimited ASCII 
file suitable for import into the ISP’s billing database. The Call 
Detail Report will normally be used by the ISP to generate end-user 
billing for roaming usage. 


5.6. Security 


All transactions between ISPs andthe i-Pass servers are 
encrypted using the SSL protocol. Public key certificates are 
verified at both the client and server. i-Pass issues these 
certificates and acts as the Cetificate Authority. 


Transactions are also verified based on a number of other criteria 
such as source IP address. 


5.7. Operations 


i-Pass operates several authentication server sites. Each site 
consists of two redundant server systems located in secure facilities 
and "close" to the Internet backbone. The authentication server 
sites are geographically distributed to minimize the possibility of 
failure due to natural disasters etc. 
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i-Pass maintains a Network Operations Center in Mountain View which 
is staffed on a 7x24 basis. Its functions include monitoring the i- 
Pass authentication servers, monitoring authentication servers 
located at partner facilities, and dealing with problem reports. 


6. ChinaNet implementation 


ChinaNet, owned by China Telecom, is China’s largest Internet 
backbone. Constructed by Asiainfo, a Dallas based system integration 
company, it has 31 backbone nodes in 31 Chinese provincial capital 
cities. Each province is building its own provincial network, has 
its own dialup servers, and administers its own user base. 


In order to allow hinaNet users to be able to access nodes outside 
their province while traveling, a nationwide roaming system has been 
implemented. The roaming system was developed by AsiaInfo, and is 
based on the RADIUS protocol. 


6.1. Phone number presentation 
Since China Telecom uses one phone number (163) for nationwide 
Internet access, most cities have the same Internet access number. 
Therefore a phone book is not currently required for the ChinaNet 
implementation. A web-based phone book will be added in a future 
software release in order to support nationwide ISP/CSP telephone 
numbers and HTTP server addresses. 


6.2. Connection management 


The current roaming client and server supports both PPP and SLIP. 


6.3. Address assignment and routing 
ChinaNet only supports dynamic IP address assignment for roaming 
users. In addition, static addresses are supported for users 
authenticating within their home province. 


6.4. Authentication 


When user accesses a local NAS, it provides its userID either as 


"username" or "username@realm". The NAS will pass the userID and 
password to the RADIUS proxy/server. If the "username" notation is 
used, the Radius proxy/server will assume that the user is a local 
user and will handle local authentication accordingly. If "user- 


name@realm" is used, the RADIUS proxy/server will process it as a 
roaming request. 
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When the RADIUS proxy/server handles a request from a roaming user, 
it will first check the cache to see if the user information is 
already stored there. If there is a cache hit, the RADIUS 
proxy/server do the local authentication accordingly. If it does not 
find user information in its cache, it will act as a proxy, 
forwarding the authentication request to the home RADIUS server. 

When the home RADIUS server responds, the local server will forward 
the response to the NAS. If the user is authenticated by the home 
server, the local RADIUS proxy will cache the user information for a 
period of time (3 days by default). 


Caching is used to avoid frequent proxying of requests and responses 
between the local RADIUS proxy and the home RADIUS server. When the 
home RADIUS server sends back a valid authentication response, the 
local RADIUS proxy/server will cache the user information for a 
period of time (3 days by default). When the user next authenticates 
directly against the home RADIUS server, the home RADIUS server will 
send a request to the local server or servers to clear the user’s 
information from the cache. 


6.4.1. Extended hierarchy 


In some provinces, the local telecommunications administration 
Provincial ISP) further delegates control to county access nodes, 
creating another level of hierarchy. This is done to improve 
scalability and to avoid having the provincial ISP databases grow too 
large. In the current implementation, each provincial ISP maintains 
its own central RADIUS server, including information on all users in 
the province, while county nodes maintain distributed RADIUS servers. 
For intra-province roaming requests the local RADIUS proxy/server 
will directly forward the request to the home RADIUS server. 


However, for inter-province roaming requests, the local RADIUS server 
does not forward the request directly to the home RADIUS server. 
Instead, the request is forwarded to the central provincial RADIUS 
server for the home province. This implementation is suitable only 
when county level ISPs do not mind combining and sharing their user 
information. In this instance, this is acceptable, since all county 
level ISPs are part of China Telecom. In a future release, this 
multi-layer hierarchy will be implemented using multi-layer proxy 
RADIUS, in a manner more resembling DNS. 


6.5. Security 
Encryption is used between the local RADIUS proxy/server and the home 
RADIUS server. Public/Private key encryption will be supported in the 


next release. IP tunneling and token card support is under 
consideration. 
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6.6. Accounting 


Accounting information is transferred between the local RADIUS 
accounting proxy/server and home RADIUS accounting server. Every day 
each node sends a summary accounting information record to a central 
server in order to support nationwide settlement. The central server 
is run by the central Data Communication Bureau of China Telecom. 
Every month the central server sends the settlement bill to the 
provincial ISPs. 


6.7. Inter-ISP/CSP roaming 


ChinaNet supports both ISP and CSP (Content Service Provider) roaming 
on its system. For example, Shanghai Online, a Web-based commercial 
content service, uses RADIUS for authentication of ChinaNet users who 
do not have a Shanghai Online account. In order to support this, the 
Shanghai Online servers function as a RADIUS client authenticating 
against the home RADIUS server. When users access a protected 
document on the HTTP server, they are prompted to send a 
username/password for authentication. The user then responds with 
their userID in "user-name@realm" notation. 


A CGI script on the HTTP server then acts as a RADIUS authentication 
client, sending the request to the home RADIUS server. After the home 
RADIUS server responds, the CGI script passes the information to the 
local authentication agent. From this point forward, everything is 
taken care of by the local Web authentication mechanism. 


7. Microsoft implementation 


Microsoft’s roaming implementation was originally developed in order 
to support the Microsoft Network (MSN), which now offers Internet 
access in seven countries: US, Canada, France, Germany, UK, Japan, 
and Australia. In each of these countries, service is offered in 
cooperation with access partners. Since users are able to connect to 
the access partner networks while maintaining a customer-vendor 
relationship with MSN, this implementation fits within the definition 
of roaming as used in this document. 


7.1. Implementation overview 
The first version of the Microsoft roaming software was deployed by 
the MSN partners in April, 1996. This version included a Phone Book 


manager tool running under Windows 95, as well as a RADIUS 
server/proxy implementation running under Windows NT; TACACS+ is 
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currently not supported. Additional components now under development 
include a Connection Manager client for Windows 95 as well as an 
HTTP-based phone book server for Windows NT. The Phone Book manager 
tool is also being upgraded to provide for more automated phone book 
compilation. 


7.2. Phone number presentation 


The Connection Manager is responsible for the presentation and 
updating of phone numbers, as well as for dialing and making 
connections. In order to select phone numbers, users are asked to 
select the desired country and region/state. Phone numbers are then 
presented in the area selected. The primary numbers are those from 
the users service provider which match the service type (Analog, 
ISDN, Analog & IDN), country and region/state selected. The other 
numbers (selected clicking on the More button) are those for other 
service providers that have a roaming agreement with the users 
service provider. 


7.2.1. Cost data 


Cost data is not presented to users along with the phone numbers. 
However, such information may be made available by other means, such 
as via a Web page. 


7.2.2. Default phone book format 


The Connection Manager supports the ability to customize the phone 
book format, and it is expected that many ISPs will make use of this 
capability. However, for those who wish to use it "off the shelf" a 
default phone book format is provided. The default phone book is 
comprised of several files, including: 


Service profile 
Phone Book 
Region file 


The service profile provides information on a given service, which 
may be an isolated Internet Service Provider, or may represent a 
roaming consortium. The service profile, which is in .ini file 
format, is comprised of the following information: 


The name of the service 

The filename of the service’s big icon 
The filename of the service’s little icon 
A description of the service 

The service phone book filename 
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The service phone book version number 
The service regions file 
The URL of the service phone book server 
The prefix used by the service (i.e. "MSN/aboba") 
The suffix or domain used by the service (i.e. "aboba@msn.com") 
Whether the user name is optional for the service 
Whether the password is optional for the service 
Maximum length of the user name for the service 
Maximum length of the password for the service 
Information on service password handling (lowercase, mixed case, etc.) 
Number of redials for this service 
Delay between redials for this service 
References to other service providers that have roaming agreements 
The service profile filenames for each of the references 
Mask and match phone book filters for each of the references 
(these are 32 bit numbers that are applied against the capability 
flags in the phone book) 
The dial-up connection properties configuration 
(this is the DUN connectoid name) 


The phone book file is a comma delimited ASCII file containing the 
following data: 


Unique number identifying a particular record (Index) 
Country ID 

A zero-base index into the region file 

City 

Area code 

Local phone number 

Minimum Speed 

Maximum speed 

Capability Flags: 


Bit 0: O=Toll, 1=Toll free 

Bit 1: O=X25, 1=IP 

Bit 2: O=Analog, 1=No analog support 

Bit 3: O=no ISDN support, 1=ISDN 

Bit 4: 0 

Bit 5: 0 

Bit 6: O=No Internet access, 1=Internet access 


Bit 7: O=No signup access, 1=Signup access 
Bit 8-31: reserved 
The filename of the dialup network file 
(typically refers to a script associated with the number) 
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7 


so 


23 


A sample phone book file is shown below: 


65031,1,1,Aniston, 205, 5551212, 2400,2400,1,0,myfile 
200255,1,1,Auburn/Opelika, 334,5551212, 9600, 28800,0,10, 
200133,1,1,Birmingham, 205,5551212, 9600, 28800,0,10, 
130,1,1,Birmingham, 205, 3275411, 9600, 14400, 9,0, yourfile 
65034,1,1,Birmingham, 205, 3285719, 9600,14400,1,0,myfile 


3. Additional attributes 


As described previously, it is likely that some ISPs will require 
additional phone number attributes or provider information beyond 
that supported in the default phone book format. Attributes of 
interest may vary between providers, or may arise as a result of the 
introduction of new technologies. As a result, the set of phone 
number attributes is likely to evolve over time, and extensibility in 
the phone book format is highly desirable. 


For example, in addition to the attributes provided in the default 
phone book, the following additional attributes have been requested 
by customers: 


Multicast support flag 

External/internal flag (to differentiate display between the 
"internal" or "other" list box) 

Priority (for control of presentation order) 

Modem protocol capabilities (V.34, V.32bis, etc.) 

ISDN protocol capabilities (V.110, V.120, etc.) 

No password flag (for numbers using telephone-based billing) 

Provider name 


4. Addition of information on providers 


The default phone book does not provide a mechanism for display of 
information on the individual ISPs within the roaming consortium, 
only for the consortium as a whole. For example, the provider icons 
(big and little) are included in the service profile. The service 
description information is expected to contain the customer support 
number. However, this information cannot be provided on an 
individual basis for each of the members of a roaming consortium. 
Additional information useful on a per-provider basis would include: 


Provider voice phone number 

Provider icon 

Provider fax phone number 

Provider customer support phone number 
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7.3. Phone number exchange 


Currently phone number exchange is not supported by the phone book 
server. As a result, in the MSN implementation, phone number exchange 
is handled manually. As new POPs come online, the numbers are 
forwarded to MSN, which tests the numbers and approves them for 
addition to the phone book server. Updated phone books are produced 
and loaded on the phone book server on a weekly basis. 


7.4. Phone book compilation 


The Phone Book Manager tool was created in order to make it easier 
for the access partners to create and update their phone books. It 
supports addition, removal, and editing of phone numbers, generating 
both a new phone book, as well as associated difference files. 


With version 1 of the Phone Book Administration tool, phone books are 
compiled manually, and represent a concatenation of available numbers 
from all partners, with no policy application. With version 1, the 
updates are prepared by the partners and forwarded to MSN, which 
tests the numbers and approves them for addition to the phone book. 
The updates are then concatenated together to form the global update 
file. 


The new version of the Phone Book Administration tool automates much 
of the phone book compilation process, making it possible for phone 
book compilation to be decentralized with each partner running their 
own phone book server. Partners can then maintain and test their 
individual phone books and post them on their own Phone Book Server. 


7.5. Phone book update 


There is a mechanism to download phone book deltas, as well as to 
download arbitrary executables which can perform more complex update 
processing. Digital signatures are only used on the downloading of 
executables, since only these represent a security threat - the 
Connection Manager client does not check for digital signatures on 
deltas because bogus deltas can’t really cause any harm. 


The Connection Manager updates the phone book each time the user logs 
on. This is accomplished via an HTTP GET request to the phone book 
server. When the server is examining the request, it can take into 
account things like the OS version on the client, the language on the 
client, the version of Connection Manager on the client, and the 
version of the phone book on the client, in order to determine what 
it wants to send back. 
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In the GET response, the phone book server responds with the 
difference files necessary to update the client’s phone book to the 
latest version. The client then builds the new phone book by 
successively applying these difference files. This process results 
in the update of the entire phone book, and is simple enough to allow 
it to be easily implemented on a variety of HTTP servers, either as a 
CGI script or (on NT) as an ISAPI DLL. 


The difference files used in the default phone book consist of a 
list of phone book entries, each uniquely identified by their index 
number. Additions consist of phone book entries with all the 
information filed in; deletions are signified by entries with all 
entries zeroed out. A sample difference file is shown below: 


65031,1,1,Aniston, 205,5551212,2400,2400,1,0,myfile 
200255,1,1,Auburn/Opelika, 334,5551212, 9600, 28800,0,10, 
200133,0,0,0,0,0,0,0,0,0 
130,1,1,Birmingham, 205,5551211, 9600,14400,9,0,yourfile 
65034,1,1,Birmingham, 205,5551210,9600,14400,1,0,myfile 


7.6. Connection management 


The Connection Manager can support any protocol which can be 
configured via use of Windows Dialup Networking, including PPP and 
SLIP running over IP. The default setting is for the IP address as 
well as the DNS server IP address to be assigned by the NAS. The DNS 
server assignment capability is described in [1]. 


7.7. Authentication 


The Connection Manager client and RADIUS proxy/server both support 
suffix style notation (i.e. "aboba@msn.com"), as well as a prefix 
notation ("MSN/aboba") . 


The prefix notation was developed for use with NAS devices with small 
maximum userID lengths. For these devices the compactness of the 
prefix notation significantly increases the number of characters 
available for the userID field. However, as an increasing number of 
NAS devices are now supporting 253 octet userIDs (the maximum 
supported by RADIUS) the need for prefix notation is declining. 


After receiving the userID from the Connection Manager client, the 
NAS device passes the userID/domain and password information (or in 
the case of CHAP, the challenge and the response) to the RADIUS 
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proxy. The RADIUS proxy then checks if the domain is authorized for 
roaming by examining a static configuration file. If the domain is 
authorized, the RADIUS proxy then forwards the request to the 
appropriate RADIUS server. The domain to server mapping is also made 
via a static configuration file. 


While static configuration files work well for small roaming 
consortia, for larger consortia static configuration will become 
tedious. Potentially more scalable solutions include use of DNS SRV 
records for the domain to RADIUS server mapping. 


7.8. NAS configuration/authorization 


Although the attributes returned by the home RADIUS server may make 
sense to home NAS devices, the local NAS may be configured 
differently, or may be from a different vendor. As a result, it may 
be necessary for the RADIUS proxy to edit the attribute set returned 
by the home RADIUS server, in order to provide the local NAS with the 
appropriate configuration information. The editing occurs via 
attribute discard and insertion of attributes by the proxy. 


Alternatively, the home RADIUS server may be configured not to return 
any network-specific attributes, and to allow these to be inserted by 
the local RADIUS proxy. 


Attributes most likely to cause conflicts include: 


Framed-IP-Address Framed-IP-Netmask Framed-Routing Framed-Route 
Filter-Id Vendor-Specific Session-Timeout Idle-Timeout 
Termination-Action 


Conflicts relating to IP address assignment and routing are very 
common. Where dynamic address assignment is used, an IP address pool 
appropriate for the local NAS can be substituted for the IP address 
pool designated by the home RADIUS server. 


However, not all address conflicts can be resolved by editing. In 
some cases, (i.e., assignment of a static network address for a LAN) 
it may not be possible for the local NAS to accept the home RADIUS 
server’s address assignment, yet the roaming hosts may not be able to 
accept an alternative assignment. 


Filter IDs also pose a problem. It is possible that the local NAS may 
not implement a filter corresponding to that designated by the home 
RADIUS server. Even if an equivalent filter is implemented, in order 
to guarantee correct operation, the proxy’s configuration must track 
changes in the filter configurations of each of the members of the 
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roaming consortium. In practice this is likely to be unworkable. 
Direct upload of filter configuration is not a solution either, 
because of the wide variation in filter languages supported in 
today’s NAS devices. 


Since by definition vendor specific attributes have meaning only to 
devices created by that vendor, use of these attributes is 
problematic within a heterogeneous roaming consortium. While it is 
possible to edit these attributes, or even to discard them or allow 
them to be ignored, this may not always be acceptable. In cases where 
vendor specific attributes relate to security, it may not be 
acceptable for the proxy to modify or discard these attributes; the 
only acceptable action may be for the local NAS to drop the user. 
Unfortunately, RADIUS does not distinguish between mandatory and 
optional attributes, so that there is no way for the proxy to take 
guidance from the server. 


Conflicts over session or idle timeouts may result if since both the 
local and home ISP feel the need to adjust these parameters. While 
the home ISP may wish to adjust the parameter to match the user’s 
software, the local ISP may wish to adjust it to match its own 
service policy. As long as the desired parameters do not differ too 
greatly, a compromise is often possible. 


7.9. Address assignment and routing 


While the Connection Manager software supports both static and 
dynamic address assignment, in the MSN implementation, all addresses 
are dynamically assigned. 


However, selected partners also offer LAN connectivity to their 
customers, usually via static address assignment. However, these 
accounts do not have roaming privileges since no mechanism has been 
put in place for allowing these static routes to move between 
providers. 


Users looking to do LAN roaming between providers are encouraged to 
select a router supporting Network Address Translation (NAT). NAT 
versions implemented in several low-end routers are compatible with 
the dynamic addressing used on MSN, as well as supporting DHCP on the 
LAN side. 


7.10. Security 


The RADIUS proxy/server implementation does not support token cards 
or tunneling protocols. 


Aboba, et. al. Informational [Page 22] 


RFC 2194 Review of Roaming Implementations September 1997 


7.11. Accounting 


In the MSN roaming implementation, the accounting data exchange 
process is specified in terms of an accounting record format, anda 
method by which the records are transferred from the partners to MSN, 
which acts as the settlement agent. Defining the interaction in 
terms of record formats and transfer protocols implies that the 
partners do not communicate with the settlement agent using NAS 
accounting protocols. As a result, accounting protocol 
interoperability is not be required. 


However, for this advantage to be fully realized, it is necessary for 
the accounting record format to be extensible. This makes it more 
likely that the format can be adapted for use with the wide variety 
of accounting protocols in current use (such as SNMP, syslog, RADIUS, 
and TACACS+), as well as future protocols. After all, if the record 
format cannot express the metrics provided by a particular partner’s 
accounting protocol, then the record format will not be of much 
usefor a heterogeneous roaming consortium. 


7.11.1. Accounting record format 


The Microsoft RADIUS proxy/server supports the ability to customize 
the accounting record format, and it is expected that some ISPs will 
make use of this capability. However for those who want to use it 
"off the shelf" a default accounting record format is provided. The 
accounting record includes information provided by RADIUS: 


User Name (String; the user’s ID, including prefix or suffix) 
NAS IP address (Integer; the IP address of the user’s NAS) 
NAS Port (Integer; identifies the physical port on the NAS) 
Service Type (Integer; identifies the service provided to the user) 
NAS Identifier (Integer; unique identifier for the NAS) 
Status Type (Integer; indicates session start and stop, 

as well as accounting on and off) 
Delay Time (Integer; time client has been trying to send) 
Input Octets (Integer; in stop record, octets received from port) 
Output Octets (Integer; in stop record, octets sent to port) 
Session ID (Integer; unique ID linking start and stop records) 
Authentication (Integer; indicates how user was authenticated) 
Session Time (Integer; in stop record, seconds of received service) 
Input Packets (Integer; in stop record, packets received from port) 
Output Packets (Integer; in stop record, packets sent to port) 
Termination Cause (Integer; in stop record, indicates termination cause) 
Multi-Session ID (String; for linking of multiple related sessions) 
Link Count (Integer; number of links up when record was generated) 
NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.) 
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7. 


8. 


8. 


However, since this default format is not extensible, it cannot 
easily be adapted to protocols other than RADIUS, services other than 
dialup (i.e. dedicated connections) or rated events (i.e. file 
downloads). This is a serious limitation, and as a result, customers 
have requested a more general accounting record format. 


11.2. Transfer mechanism 


Prior to being transferred, the accounting records are compressed so 
as to save bandwidth. The transfer of accounting records is handled 
via FTP, with the transfer being initiated by the receiving party, 
rather than by the sending party. A duplicate set of records is kept 
by the local ISP for verification purposes. 


Merit Network Implementation 
1. Overview 


MichNet is a regional IP backbone network operated within the state 
of Michigan by Merit Network, Inc., a nonprofit corporation based in 
Ann Arbor, Michigan. Started in 1966, MichNet currently provides 
backbone level Internet connectivity and dial-in IP services to its 
member and affiliate universities, colleges, K-12 schools, libraries, 
government institutions, other nonprofit organizations, and 
commercial business entities. 


As of May 1, 1997, MichNet had 11 members and 405 affiliates. Its 
shared dial-in service operated 133 sites in Michigan and one in 
Washington, D.C, with 4774 dial-in lines. Additional dial-in lines 
and sites are being installed daily. 


MichNet also provides national and international dial-in services to 
its members and affiliates through an 800 number and other external 
services contracting with national and global service providers. 


The phone numbers of all MichNet shared dial-in sites are published 
both on the Merit web site and in the MichNet newsletters. Merit also 
provides links to information about the national and international 
service sites through their respective providers’ web sites. Such 
information can be found at http://www.merit.edu/mich- 
net/shared.dialin/. 


-l.1. MichNet State-Wide Shared Dial-In Services 


Each MichNet shared dial-in service site is owned and maintained by 
either Merit or by a member or affiliate organization. All sites must 
support PPP and Telnet connections. 
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Each organization participating in the shared dial-in service is 
assigned a realm-name. Typically the realm-name resembles a fully 
qualified domain name. Users accessing the shared dial-in service 
identify themselves by using a MichNet AccessID which consists of 
their local id concatenated with "@" followed by the realm-name - 
e.g. user@realm 


Merit operates a set of Authentication, Authorization and Accounting 
(AAA) servers supporting the RADIUS protocol which are called core 
servers. The core servers support all the dial-in service sites and 
act as proxy servers to other AAA servers running at the 
participating organizations. For security reasons, Merit staff run 
all core servers; in particular, the user password is in the clear 
when the proxy core server decodes an incoming request and then re- 
encodes it and forwards it out again, 


The core servers also enforce a common policy among all dial-in 
servers. The most important policy is that each provider of access 
must make dial-in ports available to others when the provider’s own 
users do not have a need for them. To implement this policy, the 
proxy server distinguishes between realms that are owners and realms 
that are guests. 


One piece of the policy determining whether the provider’s 
organization has need of the port, is implemented by having the proxy 
core server track the realms associated with each of the sessions 
connected at a particular huntgroup. If there are few ports available 
(where few is determined by a formula) then guests are denied access. 
Guests are also assigned a time limit and their sessions are 
terminated after some amount of time (currently one hour during prime 
time, two hours during non-prime time). 


The other part of the policy is to limit the number of guests that 


are allowed to connect. This is done by limiting the number of 
simultaneous guest sessions for realms. Each realm is allocated a 
number of "Simultaneous access tokens" - SATs. When a guest session 


is authorized the end server for the realm decrements the count of 
available SATs, and when the session is terminated the count of SATs 
is incremented. A Merit specific attribute is added to the request 
by the core if the session will be a "guest" and will require a SAT. 
The end server must include a reply with an attribute containing the 
name of the "token pool" from which the token for this session is 
taken. The effect of this is to limit the number of guests connected 
to the network to the total number of tokens allocated to all realms. 
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Each realm is authenticated and authorized by its own AAA server. The 
proxy core servers forward requests to the appropriate server based 
on a configuration file showing where each realm is to be 
authenticated. Requests from realms not in the configuration are 
dropped. 


The Merit AAA server software supports this policy. Merit provides 
this software to member and affiliate organizations. The software is 
designed to work with many existing authentication servers, such as 
Kerberos IV, UNIX password, TACACS, TACACS+, and RADIUS. This 
enables most institutions to utilize the authentication mechanism 
they have in place. 


8.1.2. MichNet National and International Dial-In Services 


In addition to the MichNet shared dial-in service, Merit also 
provides access from locations outside of Michigan by interconnecting 
with other dial-in services. These services are typically billed by 
connect time. Merit acts as the accounting agent between its member 
and affiliate organizations and the outside service provider. 


The services currently supported are a national 800 number and 
service via the ADP/Autonet dial-in network. Connection with 
IBM/Advantis is being tested, and several other service interconnects 
are being investigated. 


Calls placed by a Merit member/affiliate user to these external 
dial-in services are authenticated by having each of those services 
forward RADIUS authentication requests and accounting messages to a 
Merit proxy core server. The core forwards the requests to the 
member/affiliate server for approval. Session records are logged at 
the Merit core server and at the member/affiliate erver. Merit bills 
members/affiliates monthly, based on processing of the accounting 
logs. The members and affiliates are responsible for rebilling their 
users. 


The Merit AAA software supports the ability to request positive 
confirmation of acceptance of charges, and provides tools for 
accumulating and reporting on use by realm and by user. 


8.2. Authentication and Authorization 


Authentication of a Telnet session is supported using the traditional 
id and password method, with the id being a MichNet AccessID of the 
form user@realm, while a PPP session may be authenticated either 
using an AccessID and password within a script, or using PAP. 

Support for challenge/response authentication mechanisms using EAP is 
under development. 
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When a user dials into a MichNet shared dial-in port, the NAS sends 
an Access-—Request to a core AAA server using the RADIUS protocol. 
First the core server applies any appropriate huntgroup access 
policies to the request. If the Request fails the policy check, an 
Access-Reject is returned to the NAS. Otherwise, the core server 
forwards it to the user’s home authentication server according to the 
user’s realm. The home authentication server authenticates and 
authorizes the access request. An Access-Accept or Access-Reject is 
sent back to the core server. If an Access-Accept is sent, the home 
server will create a dial-in session identifier which is unique to 
this session and insert it in a Class attribute in the Access-—Accept. 
The core server looks at the request and the response from the home 
server again and decides either to accept or reject the request. 
Finally, the core server sends either an Access-Accept or Access- 
Reject to the NAS. 


When a user dials into a contracted ISP’s huntgrup (MichNet National 
and International Service), the ISP sends a RADIUS access request to 
a Merit core server. The rest of the authentication and authorization 
path is the same as in the shared dial-in service, except that no 
huntgroup access policy is applied but a Huntgroup-Service attribute 
is sent to the home authentication server with its value being the 
name of the service, and a copy of the attribute must be returned by 
the home server with a flag appended to the original value to 
indicate a positive authorization of user access to the specified 
service. 


The MichNet shared dial-in service typically requires authorization 
of some sort, for example, a user dialing into a huntgroup as a guest 
must be authorized with a token from the user’s realm. Participating 
institutions have control in defining authorization rules. Currently 
authorization may be done using any combination of the user’s group 
status and user’s account status. A set of programming interfaces is 
also provided for incorporating new authorization policies. 


8.3. Accounting 


In the Merit AAA server, a session is defined as starting from the 
moment the user connects to the NAS, and ending at the point when the 
user disconnects. During the course of a session, both the core 
server and the home server maintain status information about the 
session. This allows the AAA servers to apply policies based on the 
current status, e.g. limit guest access by realm to number of 


Aboba, et. al. Informational [Page 27] 


RFC 2194 Review of Roaming Implementations September 1997 


available tokens, or to limit number of simultaneous sessions for a 
given AccessID. Information such as whether the session is for a 
guest, whether it used a token, and other information is included 
with the accounting stop information when it is logged. Merit has 
made enhancements to the RADIUS protocol, that are local to the AAA 
server, to support maintenance of session status information. 


When a user session is successfully authenticated, the NAS sends out 
a RADIUS accounting start request to the core server. The core server 
forwards that request to the user’s home server. The home server 
updates the status of the session and then responds to the core. The 
core server in turn responds to the NAS. In the accounting Start 
request, a NAS conforming to the RADIUS specification must return the 
Class attribute and value it received in the Access-Accept for the 
session, thus sending back the dial-in session identifier created by 
the session’s home server. 


When a user ends a session, an accounting stop request is sent 
through the same path. the same path. The dial-in session 
identifier is again returned by the NAS, providing a means of 
uniquely identifying a session. By configuring the finite state 
machine in each of the AAA servers, any accounting requests may be 
logged by any of the servers where the accounting requests are 
received. 


Because the same session logs are available on every server in the 
path of a session’s authorization and accounting message, problems 
with reconciliation of specific sessions may be resolved easily. For 
the shared dial-in service, there are no usage charges. Merit has 
tools to verify that organizations do not authorize more guest 
sessions than the number of SATs allocated to the organization. For 
surcharged sessions, Merit sends each organization a summary bill 
each month. Files with detail session records are available for 
problem resolution. Each organization is responsible for billing its 
own users, and should have the same session records as are collected 
by Merit. 


Merit receives a monthly invoice from other dial-in service providers 
and pays them directly, after first verifying that the charges 
correspond to the session records logged by Merit. 


8.4. Software and Development 


Merit has developed the AAA server software which supports the above 
capabilities initially by modifying the RADIUS server provided by 

Livingston, and later by doing a nearly total rewrite of the software 
to make enhancement and extension of capabilites easier. Merit makes 
a basic version of its server freely available for noncommercial use. 
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Merit has started the Merit AAA Server Consortium which consists of 
Merit and a number of NAS vedors, ISPs and server software vendors. 
The consortium supports ongoing development of the Merit AAA server. 
The goal is to build a server that supports proxy as well as end 
server capabilities, that is feature rich, and that interoperates 
with major vendors’ NAS products. 


The building block of the Merit AAA server, the 
Authentication/Authorization Transfer Vector (AATV), is a very 
powerful concept that enables the ultimate modularity and flexibility 
of the AAA server. The structure and methods of the AATV model are 
published with all versions of the AAA server. 


Objects for extending the authorization server are also available in 
the enhanced version of the AAA server. Merit is also looking at ways 
to provide a method of extending the AAA server in its executable 
form, to improve the server efficiency and scalability, and to 
provide better monitoring, instrumentation and administration of the 
server. 


9. FidoNet implementation 


Since its birth in 1984, FidoNet has supported phone book 
synchronization among its member nodes, which now number 
approximately 35,000. As a non-IP dialup network, FidoNet does not 
provide IP services to members, and does not utilize IP-based 
authentication technology. Instead member nodes offer bulletin-board 
services, including access to mail and conferences known as echoes. 


In order to be able to communicate with each other, FidoNet member 
systems require a sychronized phone book, known as the Nodelist. The 
purpose of the Nodelist is to enable resolution of FidoNet addresses 
(expressed in the form zone:network/node, or 1:161/445) to phone 
numbers. As a dialup network, FidoNet requires phone numbers in 
order to be deliver mail and conference traffic. 


In order to minimize the effort required in regularly synchronizing a 
phone book of 35,000 entries, the weekly Nodelist updates are 


transmitted as difference files. These difference files, known as 
the Nodediff, produce the Nodelist for the current week when applied 
to the previous week’s Nodelist. In order to minimize transfer time, 


Nodediffs are compressed prior to transfer. 


Information on FidoNet, as well as FidoNet Technical Standards (FTS) 
documents (including the Nodelist specification) and standards 
proposals are available from the FidoNet archive at 
http://www.fidonet.org/. 
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9.1. Scaling issues 


With a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB 
in size, and the weekly Nodediffs are 175 KB. In compressed form, the 
Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As 
a result, the transfer of the Nodediff takes approximately 45 seconds 
using a 28,800 bps modem. 


In order to improve scalability, the implementation of a domain name 
service approach is examined in [8]. The proposal evisages use of a 
capability analagous to the DNS ISDN record in order to map names to 
phone numbers, coupled with an additional record to provide the 
attributes associated with a given name. 


9.2. Phone number presentation 


While FidoNet member systems perform hone book synchronization, users 
need only know the FidoNet address of the systems they wish to 
contact. As a result users do not need to maintain copies of the 
Nodelist on their own systems. This is similar to the Internet, where 
the DNS takes care of the domain name to IP address mapping, so that 
users do not have to remember IP addresses. 


Nevertheless, FidoNet systems often find it useful to be able to 
present lists of nodes, and as a result, FidoNet Nodelist compilers 
typically produce a representation of the Nodelist that can be 
searched or displayed online, as well as one that is used by the 
system dialer. 


9.2.1. FidoNet Nodelist format 


The FidoNet Nodelist format is documented in detail in [3]. The 
Nodelist file consists of lines of data as well as comment lines, 
which begin with a semi-colon. The first line of the Nodelist is a 
general interest comment line that includes the date and the day 
number, as well as a 16-bit CRC. The CRC is included so as to allow 
the system assembling the new Nodelist to verify its integrity. 


Each Nodelist data line contains eight comma separated fields: 


Keyword 
Zone/Region/Net/Node number 
Node name 

Location 

Sysop name 

Phone number 

Maximum Baud rate 

Flags (optional) 
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FidoNet Nodelists are arranged geographically, with systems in the 
same zone, region, and network being grouped together. As a result, 
FidoNet Nodelists do not require a separate regions file. Among other 
things, the keyword field can be used to indicate that a system is 
temporarily out of service. 


Reference [3] discusses Nodelist flags in considerable detail. Among 
other things, the flags include information on supported modem 
modulation and error correction protocols. Reference [4] also 
proposes a series of ISDN capability flags, and [5] proposes flags to 
indicate times of system availability. 


9.3. Phone number exchange 


FidoNet coordinators are responsible for maintaining up to date 
information on their networks, regions, and zones. Every week network 
coordinators submit to their regional coordinators updated versions 
of their portions of the Nodelist. The regional coordinators then 
compile the submissions from their network coordinators, and submit 
them to the zone coordinator. The zone coordinators then exchange 
their submissions to produce the new Nodelist. As a result, it is 
possible that the view from different zones may differ at any given 
time. 


9.3.1. The Nodediff 


The format of the Nodediff is discussed in detail in [3]. In 
preparing the Nodediffs, network coordinators may transmit only their 
difference updates, which can be collated to produce the Nodediff 
directly. 


One weakness in the current approach is that there is no security 
applied to the coordinator submissions. This leaves oen the 
possibility of propagation of fraudulent updates. In order to address 
this, [6] proposes addition of a shared secret to the update files. 


9.3.2. Addition of nodes 


In order to apply for allocation of a FidoNet address and membership 
in the Nodelist, systems must demonstrate that they are functioning 
by sending mail to the local network coordinator. Once the local 
network coordinator receives the application, they then allocate a 
new FidoNet address, and add a Nodelist entry. 
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9.3.3. Deletion of nodes 


Since FidoNet nodes are required to be functioning during the zone 
mail hour in order to receive mail, and since nodes receive the 
weekly Nodelist from their local network coordinators on a weekly 
basis, there is a built-in mechanism for discovery of non-functional 
nodes. 


Nodes found to be down are reported to the local network coordinator 

and subsequently marked as down within the Nodelist. Nodes remaining 
down for more than two weeks may be removed from the Nodelist, at the 
discretion of the network coordinator. 


9.4. Phone book update 


The Nodelist contains the phone numbers and associated attributes of 
each participating system. New Nodelists become available on Fridays, 
and are made available to participating systems by their local 
network coordinators, who in turn receive them from the regional and 
zone coordinators. 


While it is standard practice for participating systems to get their 
Nodelists from their local network coordinators, should the local 
network coordinator not be available for some reason, either the 
updates or the complete Nodelist may be picked up from other network, 
or regional coordinators. Please note that since the view from 
different zones may differ, nodes wishing to update their Nodelists 
should not contact systems from outside their zone. 


9.5. Phone book compilation 


Once FidoNet systems have received the Nodediff, the apply it to the 
previous week’s Nodelist in order to prepare a new Nodelist. In 
order to receive Nodediffs and compile the Nodelist, the following 
software is required: 


A FidoNet-compatible mailer implementation, used to transfer files 
A Nodelist compiler 


One of the purposes of the Nodelist compiler is to apply Nodediffs to 
the previous Nodelist in order to produce an updated Nodelist. The 
other purpose is to compile the updated Nodelist into the format 
required by the particular mailer implementation used by the member 
system. It is important to note that while the Nodelist and Nodediff 
formats are standardized (FTS-—0005), as is the file transfer protocol 
(FTS-—0001), the compiled format used by each mailer is implementation 
dependent. 
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One reason that compiled formats to differ is the addition of out of 
band information to the Nodelist during the compilation process. 
Added information includes phone call costs as well as shared 
secrets. 


9.5.1. Cost data 


Although cost information is not part of the Nodelist, in compiling 
the Nodelist into the format used by the mailer, Nodelist compilers 
support the addition of cost information. This information is then 
subsequently used to guide mailer behavior. 


Since phone call costs depend on the rates charged by the local phone 
company, this information is local in nature and is typically entered 
into the Nodelist compiler’s configuration file by the system 
administrator. 


9.5.2. Shared secrets 


In FidoNet, shared secrets are used for authenticated sessions 
between systems. Such authenticated sessions are particularly 
important between the local, regional and zone coordinators who 
handle preparation and transmission of the Nodediffs. A single shared 
secret is used per system. 


9.6. Accounting 


Within FidoNet, the need for accounting arises primarily from the 
need of local, regional and zone coordinators to be reimbursed for 


their expenses. In order to support this, utilities have been 
developed to account for network usage at the system level according 
to various metrics. However, the accounting techniques are not 


applied at the user level. Distributed authentication and acounting 
are not implemented and therefore users may not roam between systems. 
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Security Considerations 


Security issues are discussed in sections 5.6 and 6.5. 


Aboba, et. al. Informational [Page 33] 


RFC 2194 Review of Roaming Implementations September 1997 


11. References 


[1] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for 
Name Server Addresses", RFC 1877, Microsoft, December 1995. 


[2] Fielding, R., et al., "Hypertext Transfer Protocol - HTTP/1.1.", 
RFC 2068, UC Irvine, January, 1997. 


[3] Baker, B., R. Moore, D. Nugent. "The Distribution 
Nodelist." FTS-0005, February, 1996. 


[4] Lentz, A. "ISDN Nodelist flags." FSC-0091, June, 1996. 


[5] Thomas, D. J. "A Proposed Nodelist flag indicating Online Times 
of a Node." FSC-0062, April, 1996. 


[6] Kolin, L. "Security Passwords in Nodelist Update Files." 
FSC-0055, March, 1991. 


[7] Gwinn, R., D. Dodell. "Nodelist Flag Changes Draft Document." 
FSC-0009, November, 1987. 


[8] Heller, R. "A Proposal for A FidoNet Domain Name 
Service." FSC-0069, December, 1992. 


[9] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote 
Authentication Dial In User Service (RADIUS)", RFC 2058, Livingston, 


Merit, Daydreamer, January 1997. 


[10] Rigney, C., "RADIUS Accounting", RFC 2059, Livingston, January 
1997. 


Aboba, et. al. Informational [Page 34] 


RFC 2194 


T2; 


Authors’ Addresses 


Bernard Aboba 
Microsoft Corporation 
One Microsoft Way 
Redmond, WA 98052 


Phone: 206-936-6605 
EMail: bernarda@microsoft.com 


Juan Lu 

AimQuest Corporation 

1381 McCarthy Blvd. 
Milpitas, California 95035 


Phone: 408-273-2730 ext. 2762 
EMail: juanlu@aimnet.net 


John Alsop 

i-Pass Alliance Inc. 

650 Castro St., Suite 280 
Mountain View, CA 94041 


Phone: 415-968-2200 
Fax: 415-968-2266 
EMail: jalsop@ipass.com 


James Ding 

Asiainfo 

One Galleria Tower 
13355 Noel Road, #1340 
Dallas, TX 75240 


Phone: 214-788-4141 
Fax: 214-788-0729 
EMail: ding@bjai.asiainfo.com 


Wei Wang 

Merit Network, Inc. 

4251 Plymouth Rd., Suite C 
Ann Arbor, MI 48105-2785 


Phone: 313-764-2874 
EMail: weiwang@merit.edu 


Aboba, et. al. Informational 


Review of Roaming Implementations 


September 1997 


[Page 35] 


